So when I started building this site I initially thought of just a static site generator like Pelican, something to read markdown files and create a website. That was pretty easy to cobble together in Rust with Rocket and Tera templates for the routing and renderer. Then I wanted more information than I could just get out of the filesystem. So I started turning my helper library into something more.

First there were files for extra pieces of meta data, then manually set content lists, now content types and content classes. It’s getting to the point where I can focus on writing content again without doing any coding to support site growth now. So it’s basically a CMS, just without the content indexing, but that’s coming soon.

The meta data files instantly became the schema for the data. The design grew organically instead of something planned out, as I needed something I added it. It looks like this:

Introduction.content_meta

{  
 "content_icon": "/static/images/codesandbox.svg",  
 "description": "This language is something special",  
 "timestamp_override": null,  
 "weight": 100,  
 "author": "Gatewaynode",  
 "license": "cc-by-sa",  
 "content_list": [  
   "blog/Web scraping with Rust.md",  
   "blog/Webpack build caching errors....md",  
   "blog/Feed reading with Rust.md"  
 ],
 "content_type": "page",  
 "content_class": "basic-page"
}

I used JSON to organize the data and make serialization standard and well supported. Changes to schema could be implemented with simple text file techniques so common on *nix systems. So that say a schema update on the .content_meta files was just a find and sed operation. Like adding a field:

find . -iname "*.content_meta" -exec sed -i ’s/\"page\"$/\"page\",\n  \"content_class\": \"basic-page\"/g’ {} \;

So that code line might be intimidating to some folks, I understand, that’s why I’m calling it "A power users" CMS. My intent is not to leave it that way, but a GUI and convenience tools will be lower priority than CLI and *nix tools.

Manually updating schema like that is probably not what you want long term, but I can build better metadata schema integrity in the content management system as it is needed. Which is not right now as my bash foo can get me by.

As this started to come together I decided that a radical simplicity approach should be the basis of content. So all content and metadata will be in text files, and I think this is design decision I’m going to stick with.

This doesn’t preclude using databases in the future, it just defines that any such database will not be the source of truth for content and data, but instead will be derivatives of the content and data. This could lead to text files being intermediary devices in web more applicationy use, but I like the redundancy.

This approach also means a more segregated security posture is possible by sticking to *nix style approach to file access and layer on top of that remote access controls. Security wise this means there is going to be a strong need to protect against malicious injection in things like file names. These are all fairly well walked paths though so it should be pretty easy to keep things secure as I move the system from single user to multi-user.